Skip to main content

Tunnel Address Mappings Can Override Each Other

Issue​

Designer tunnel connections can interfere with each other when several developers work with different Windows users on the same physical Windows machine or jump host.

The first developer who opens a tunnel usually does not notice a problem. For example, if this developer opens a tunnel to the test file browser, the file browser is available at 127.0.0.1:8080 or localhost:8080.

On Windows, this local tunnel is not isolated to the Windows user who opened it. The tunnel is available for all users on the same machine.

This can lead to two effects:

  • All developers on the machine can access the test file browser through 127.0.0.1:8080 or localhost:8080, even if they did not open the tunnel themselves.
  • If another developer opens a separate tunnel, for example to production, the local address can still point to the test file browser.

The same problem can also affect database connections.

Current status​

The issue is known and currently documented as unresolved.

The behavior is unstable because the mapping decision depends on a mix of hosts-file state, JVM-local static mapper state, local port availability, tunnel implementation details, Windows user sessions, and connection timing.

Decision​

Fixing this properly would require a broader redesign of Designer Tunnel address ownership, persistence, cleanup, and concurrency handling.

That effort is currently disproportionate to the known impact, so this issue remains documented as unresolved.

Workarounds​

Use Dedicated Loopback Addresses Instead of Designer Tunnels​

Do not use the Designer tunnel feature in this setup. Use a dedicated tunnel script instead.

The developers who share the same Windows machine should agree on separate loopback subnets. Each developer then uses a different address range for their tunnels.

For example:

  • Developer 1 uses 127.0.1.1 for the file browser and 127.0.1.2 for the database.
  • Developer 2 uses 127.0.2.1 for the file browser and 127.0.2.2 for the database.

This avoids collisions between tunnels opened by different Windows users on the same machine.

The following batch file shows the basic structure:

@echo off
set SERVER_ADR=ssp.adito.xy.com
set SERVER_PORT=1023
set SERVER_USER=prod-xrm-adito-xy-com

plink.exe ^
-C ^
-v ^
-N ^
-l %SERVER_USER% ^
-i "%USERPROFILE%\.ssh\id_rsa" ^
-P %SERVER_PORT% ^
-L 127.0.1.2:3306:adito-db.prod-xrm-adito-xy-com.svc.cluster.local:3306 ^
-L 127.0.1.1:8080:filebrowser.prod-xrm-adito-xy-com.svc.cluster.local:8080 ^
%SERVER_ADR%

PAUSE

The relevant lines are the two lines that start with -L. These lines define the local tunnels.

In day-to-day work, the file browser and the database are usually sufficient. Other tunnel mappings can be removed if they are not needed.

In the example above:

  • 127.0.1.1:8080 opens the file browser tunnel.
  • 127.0.1.2:3306 opens the database tunnel.

A second developer could use 127.0.2.1 and 127.0.2.2 instead, so their tunnels do not collide with the first developer's tunnels.

Update the Hosts File​

The hosts file must also be adjusted for the user-specific loopback addresses.

warning

The Designer may overwrite the hosts file again when a tunnel is opened or closed in the Designer.

Because of this, avoid opening or closing Designer tunnels after switching to the manual script-based workaround.